Skip to content

[Clipboardchange] - Event handler contains native mime types #52714

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 22, 2025

Conversation

chromium-wpt-export-bot
Copy link
Collaborator

As per the latest explainer changes, to make clipboardchange event
interop, the API should let it's clients read native clipboard mime
types using the event handler, without making any additional API calls.
To reduce the risk of fingerprinting attacks, this API intentionally omits support for exposing custom MIME types.

This CL ensures that the clipboardchange event contains native mime type
as part of event payload. Just before renderer is about to dispatch the
event (after focus check), the renderer requests the browser process for
available mime types using an existing method. The list is filtered to
only contain Chromium supported native mime types (a hard-coded list).

Considered alternative: Instead of renderer requesting for types just
before event dispatch, the browser could instead send types as part of
OnClipboardChange MOJOM call, reducing 1 mojo call. However this is not
efficient when there are multiple frames listening to the clipboard
since all the frames will try to read the available types in quick
succession which can cause performance issue.

Bug: 41442253
Change-Id: I5a0d5335c1a007f496aacbd039a59382db596904
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6511791
Reviewed-by: Dan Clark <[email protected]>
Commit-Queue: Rohan Raja <[email protected]>
Reviewed-by: Sambamurthy Bandaru <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1463867}

As per the latest explainer changes, to make clipboardchange event
interop, the API should let it's clients read native clipboard mime
types using the event handler, without making any additional API calls.
To reduce the risk of fingerprinting attacks, this API intentionally omits support for exposing custom MIME types.

This CL ensures that the clipboardchange event contains native mime type
as part of event payload. Just before renderer is about to dispatch the
event (after focus check), the renderer requests the browser process for
available mime types using an existing method. The list is filtered to
only contain Chromium supported native mime types (a hard-coded list).

Considered alternative: Instead of renderer requesting for types just
before event dispatch, the browser could instead send types as part of
OnClipboardChange MOJOM call, reducing 1 mojo call. However this is not
efficient when there are multiple frames listening to the clipboard
since all the frames will try to read the available types in quick
succession which can cause performance issue.

Bug: 41442253
Change-Id: I5a0d5335c1a007f496aacbd039a59382db596904
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6511791
Reviewed-by: Dan Clark <[email protected]>
Commit-Queue: Rohan Raja <[email protected]>
Reviewed-by: Sambamurthy Bandaru <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1463867}
Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The review process for this patch is being conducted in the Chromium project.

@chromium-wpt-export-bot chromium-wpt-export-bot merged commit a238c9e into master May 22, 2025
21 checks passed
@chromium-wpt-export-bot chromium-wpt-export-bot deleted the chromium-export-046577ab49 branch May 22, 2025 05:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants